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ABSTRACT 

We present a dependently typed assembly language (DTAL) 
in which the type system supports the use of a restricted 
form of dependent types, reaping some benefits of dependent 
types at the assembly level. DTAL improves upon TAL, 
enabling certain important compiler optimizations such as 
run-time array bound check elimination and tag check elim- 
ination. Also, DTAL formally addresses the issue of rep- 
resenting sum types at assembly level, making it suitable 
for handling not only datatypes in ML but also dependent 
datatypes in Dependent ML (DML). 

1. INTRODUCTION 

A compiler for a realistic programming language is often 
large and complex. Though it is highly desirable to establish 
the correctness of such a compiler, there seems no effective 
approach to reaching this goal currently. Instead, the on- 
going research on certifying compilers attempts to partially 
address this problem from a different angle. 

Suppose we have a compiler that translates source pro- 
gram e into target code |e|; if e possesses some property P 
(e.g. e is terminating) that we know |e| must also possess if 
the compiler is implemented correctly, we can then design 
the compiler to produce a verifiable certificate asserting that 
|e| possesses the property P; if the certificate is successfully 
verified, our confidence in the compiler is raised; otherwise, 
a compiler error needs to be located and then fixed. 

In DML [18, 13], a functional programming language that 
supports the use of a restricted form of dependent types, a 
well-typed program is both type safe (which excludes, for ex- 
amples, programs that attempt to add an integer to a float- 
ing point number) and memory safe (which excludes stray 
memory accesses). If we compile a well- typed program in 
DML into some target code at assembly level, the target 
code should also be both type safe and memory safe. Obvi- 
ously, the immediate question is how both type safety and 
memory safety can be captured at assembly level. In this 
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paper, we address this question by designing a dependently 
typed assembly language in which the dependent types can 
capture both type safety and memory safety. 

Specific approaches to certification include proof-carrying 
code (PCC) (adopted in Touchstone [8]) and type systems 
(adopted in TIL [11]). In PCC, both type safety and mem- 
ory safety are expressed by (first-order) logic assertions about 
program variables and are checked by a verification condi- 
tion generator and a theorem prover, and code is then certi- 
fied by an explicit representation of the proof. In TIL, type 
safety is expressed by type annotations and is checked by 
a type checker and no additional certification is required. 
The Touchstone approach draws on established results for 
verification of first-order imperative programs. The TIL ap- 
proach draws on established methods for designing and im- 
plementing type systems, making it unclear ( a priori) that 
it can be extended to low-level languages or to account for 
memory safety. 

Typed Assembly Language [7] is introduced by Morrisett 
et al., where a form of type system is designed at assembly- 
level suitable for compiling functional languages and a com- 
pilation from System F to TAL is given. TAL provides both 
type safety and memory safety, but at the cost of making 
critical instructions such as array subscripting atomic to en- 
sure memory safety. For instance, each array subscripting 
instruction in TAL involves checking whether a given array 
index is between the lower and upper bounds of the array 
before fetching the data item. 

We enrich TAL to allow for more fine-grained control over 
memory safety so as to support array bound check elimina- 
tion, hoisting bound checks out of loops, efficient representa- 
tion of sum types, etc. We draw on the formalism of depen- 
dent types to extend TAL with such a concept. However, 
we cannot rely directly on standard systems of dependent 
types [4] for languages with computational effects. For in- 
stance, it is entirely unclear what it means to say that A 
is an array of length x for some mutable variable x: if we 
update x with a different value, this changes the type of 
A but A itself is unchanged! Drawing on our experience 
with a restricted form of dependent types in DML [18], we 
introduce a clear separation between ordinary run-time ex- 
pressions and a distinguished family of index expressions, 
linked by singleton types of form int(x): every integer ex- 
pression of type int(x) must have value equal to x. The 
index expressions are chosen from an integer domain in this 
paper. Given an expression e (in DML), checking whether 
e has type int(x) (written as e : int(x)) involves non-trivial 
equational reasoning about the run-time behavior of e. For 




{m:nat, n:nat I m <= n} 
void copy (int src [m] , int dst [n] ) { 
var: int i, length;; 
length = arraysize (src) ; 
for (i = 0; i < length; i = i + 1) { 
dst [i] = src [i] ; 

> 

return; 

} 

Figure 1: A copy function in Xanadu 



instance, e : int(3) means that e, when evaluated, must eval- 
uate to 3. Clearly, 3 : int(3), and perhaps, 1 + 2 : int(3), but 
it is, in general, undecidable whether an arbitrary (possibly 
effectful) e has type int (3). This is where theorem proving 
and constraint satisfaction comes into the picture. 

It is difficult to read assembly code. In the following pre- 
sentation, we will occasionally use programs in Xanadu [15], 
a dependently typed imperatively programming language 
with C-like syntax, to facilitate the presentation of DTAL. 
We could also use programs in DML for this purpose but the 
great difference between DML and DTAL would make this 
alternative less desirable. The Xanadu program in Figure 1 
implements a copy function on arrays. The function header 
in the program states that for all natural numbers m and 
n satisfying m < n the function takes two integer arrays of 
sizes m and n, respectively, and returns no value. Note that 
{m : nat , n : nat I m <= n} is a universal quantifier and 
int src [m] and int dst [n] 

mean that src and dst are integer arrays of sizes m and 
n, respectively. We use var: to start variable declaration, 
which ends with ; ; . Furthermore, the function arraysize 
returns the size of an array. Note that the type index m is 
not available at run-time and we use arraysize here to get 
an integer equal to m (or literally, an integer of type int(m)). 

The DTAL code in Figure 2 corresponds to the Xanadu 
program. Note that rl, . . . ,r5 are registers. The instruc- 
tion arraysize r3, rl is non-standard, which means that 
we store into r3 the size of the array to which rl points. 
The branch instruction bgte r5, finish jumps to the la- 
bel finish if the integer in r5 is greater than or equal to 
zero. Also load r5, rl(r4) means that we store into r5 
the content of the zth cell in the array to which rl points, 
where i is the integer stored in r4. The store instruction is 
interpreted similarly. 

Every label in the code is associated with a dependent 
type. The dependent type associated with the label loop 
basically means that there exist a natural number m and a 
natural number n satisfying m < n and a natural number i 
such that rl, r2, r3, r4 are of types int array (m), int 
array (n) , int(m), int(i), respectively, that is, they are 
an integer array of size m, an integer array of size n, an 
integer of value m and an integer of value i. This enables 
us to state, for instance, that the type of rl depends on the 
value in r3. The type system of DTAL guarantees that these 
properties are satisfied when the code execution reaches the 
label loop. 

The DTAL code is well-typed, which guarantees that the 
integer in r4 is always a natural number and its value is al- 
ways less than the size of the array to which rl (r2) points 



when the load (store) instruction is executed. 1 In other 
words, it can be statically verified that there is no need 
for run-time array bound checking in this case. Although 
this is a very simple example, it is nonetheless impossible 
to infer that the store instruction is safe without the depen- 
dent type associated with the label loop. In DTAL, array 
access is separated from array bound checks and the type 
system of DTAL guarantees that the execution of well-typed 
DTAL can never perform out-of-bounds array access. It is 
this separation that makes array bound check elimination 
possible. In the case where it is impossible to prove in the 
type system of DTAL whether an array access may be out- 
of-bounds, run-time array bound checks can be inserted to 
ensure safety. 

We also address in DTAL the issue of representing sum 
types at assembly level. Furthermore, we demonstrate how 
dependent datatypes in DML can be translated into DTAL, 
allowing, for instance, an implementation of the list reverse 
function in DTAL that uses the type system of DTAL to 
guarantee this function to be length-preserving. 

In a realistic setting, machine-level arithmetic is often 
modulo a power of 2, say, 2 32 . This can be readily handled 
in our framework. For instance, we can assign the follow- 
ing type to + for handling (unsigned) addition modulo 2 32 , 
where ints 2 is the sort {a : int | 0 < a < 2 32 }. 

IE : mt 32 -IIj : mf 32 .int(«) * int(y) — > int((i + j) mod 2 32 ) 

The reason that we do not treat modulo arithmetic in this 
paper is merely for a less involved presentation. 

The main contribution of the paper is a formulation of a 
dependent type system for a language at assembly level that 
(a) is non-trivial for reasons outlined previously, (b) gener- 
alizes TAL to allow for capturing significant loop-based op- 
timizations, (c) yields an application of dependent types to 
managing low-level representation of sum types, setting up 
some machinery needed for compiling dependent datatypes 
supported in DML into assembly level, and (d) provides an 
approach to certification based on type-checking. One trade- 
off is that we presume that the constraint solver is part of 
trusted computing base in order for the recipient to verify 
the code it receives. Future work might include some means 
of formally representing proofs of constraints so that the 
constraint solver can be moved out of the trusted comput- 
ing base. 

Also, it is to be studied what are the advantages and dis- 
advantages of using a DTAL- like language as the target lan- 
guage of a compiler. When compared with the work in DML 
and Xanadu, novelties in DTAL include: 

• Datatype representation at assembly level. For in- 
stance, assume that a function in DML is given the 
type Ila : nat.(a)list(n) — ♦ ( a)list(n ), that is, it is 
length preserving; how can such a property be trans- 
lated into low-level code? 

• Control flow at assembly level that involves dependent 
types. There are simply no jumps, conditional or un- 
conditional, in either DML or Xanadu, but we have to 
deal with such language features in DTAL. 

In general, the design of DML and Xanadu is more con- 
cerned with type inference while the design of DTAL is more 

1 This point should become clear if one reasons about in- 
struction 4 and 5 in the code. 
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04. 




sub 


r5 , r4, r3 


// 


r5 <- r4 - 
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05. 




bgte 


r5, finish 


// 


r4 >= r3 








06. 




load 


r5 , rl (r4) 


// 


safe load 
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store 


r2(r4), r5 


// 


safe store 
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// 
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09. 




j m P 


loop 


// 


loop again 








10. 


finish: 


[] 














11. 




halt / / 


it can also return to the caller 


if needed 





Figure 2: A copy function implemented in DTAL 



concerned with type checking as the types in DTAL are to 
be generated by a compiler. For instance, some of the typ- 
ing rules in DTAL are not syntax directed, and annotations 
may need to be generated by a compiler in DTAL code to 
direct type-checking. We consider this to be a crucial point 
in the design of DTAL. 

We organize the paper as follows. The syntax of DTAL 
is given in Section 2. We then form evaluation and typ- 
ing rules so as to assign dynamic and static semantics to 
DTAL, respectively. We, however, postpone until Section 3 
the treatment of constraints, which are generated during 
type-checking programs in DTAL. In Section 4, we give a de- 
tailed example explaining how type-checking is performed in 
DTAL. The soundness of the type system of DTAL is stated 
in Section 5 and an extension of DTAL to handle sum types 
is given in Section 6. We then in Section 7 mention a type- 
checker for DTAL and a compiler which compiles Xanadu, a 
language resembling Safe C [9] and Popcorn [6] with C-like 
syntax, into DTAL. The rest of the paper discusses some 
closely related work and future directions. 

2. DTAL 

In this section we present a dependency typed assembly 
language (DTAL), forming both dynamic and static seman- 
tics for DTAL. 

2.1 Syntax 

We assume that there are a fixed number n r of regis- 
ters. A register file R is a finite mapping from the set 
{0, 1, . . . , n r — 1} into types. The intent is to capture some 
type information on registers with R. The syntax for DTAL 
is given in Figure 3. Note that stacks, which are treated in 
[16], are omitted here for simplicity, though we do use stacks 
in some code example. One may simply think of a stack as 
an infinite list of registers. Also, we omit tuples, which can 
be handled as in TAL. 

Intuitively speaking, dependent types are types which de- 
pend on the values of language expressions. For instance, 
we may form a type (int)array(a:) to mean that every heap 
pointer of this type points to an integer array of size x, 
where x is the expression on which this type depends. We 
use the name type index expression for such an expression. 
We restrict type index expressions to an integer domain. 
The justification for this choice is that we have used this 



domain to eliminate array bound checks effectively [17]. 

We present the syntax for type index expressions in Fig- 
ure 4, where we use a to range over type index variables and 
i for fixed integers. Note that the language for type index 
expressions is typed. We use sorts for the types in this lan- 
guage in order to avoid potential confusion. We use • for the 
empty index context and omit the standard sorting rules for 
this language. The subset sort (0:7! P} stands for the sort 
for those elements of sort 7 satisfying the proposition P. For 
example, we use nat as an abbreviation for { a : int \ a > 0}. 

We postpone the treatment of constraint satisfaction in 
this type index language until Section 3 for simplicity of 
exposition. However, we informally explain the need for 
constraints through the DTAL code in Figure 2. Notice that 
register r4 is assumed to be of type int(ii) for some natural 
number i 1 when the execution reaches the label loop. The 
type of r4 changes into int(«i + 1) after the execution of 
the instruction add r4, r4, 1. Then the execution jumps 
back to the label loop. This jump requires it to be verified 
(among many other requirements) that r4 is of type int(i2) 
for some natural number *2- Therefore, we need to prove 
that i\ + 1 is a natural number under the condition that *i 
is a natural number. This is a constraint, though it is trivial 
in this case. In general, type-checking in DTAL involves 
solving a great number of constraints of this form. 

We use top for the type of uninitialized registers and as- 
sume that a register is initialized if it is not of type top. A 
block B = AAA rf>.(R, I) roughly means that B is polymor- 
phic in type variable context A and index variable context 
<j>. We may omit AA ( X (/> ) if A (0) is empty. In order to 
execute the block on an abstract machine, we need to find 
substitutions 0 and 8 for A and (j>, respectively, such that 
the current machine state entails the state i?[0][$] and then 
execute /[Q] [8], The entailment of R means that the type 
assignment to registers in R correctly reflects the types of 
registers in the current abstract machine. For instance, if R 
indicates that an integer is in a register r, then an integer 
must be stored in r in the abstract machine. A state type 
state(XA.X(f>.R), when associated with a label, means that 
there are substitutions 0 and 8 for A and cj>, respectively, 
such that the current abstract machine state entails _R[0][$] 
whenever the execution reaches the label. The explanation 
here assumes that we carry types around when we evaluate 
DTAL code. Of course, we do not actually need to carry 




type variables 


a 






state types 


a 


:= 


state(XA.X4>.R) 


regfile types 


R 


: = 


[Vo : T"o, . . . , Vn r — 1 I Tn r — l] 


types 


r 


:= 


a | a | top | unit int(x) r array(x) | 3<^.r 


type erasures 


€ 


:= 


a | top | unit \ int | e array 


type variable contexts 


A 


:= 


'tv A, OL 


registers 


r 


:= 


r 0 , . . . ,r„ r _i 


instructions 


ins 




aop Td, r s , v | bop r, v \ arraysize rd, r s 
mo v r,v | load Td, r s (v) \ store rd(v),v s \ 
newarray[r] r, r , ,r ,, | jmp v j halt 


fixed integers 


i 


:= 


... | -1 | 0 | 1 1 ... 


constants 


c 


:= 


ON* 


values 


V 


:= 


c | r 


instruction sequences 


I 


:= 


jmp v | halt | ins ; I 


blocks 


B 


:= 


XA.X <j>.(R,I) 


arithmetic ops 


aop 


:= 


add | sub j mul | div 


branch ops 


bop 


:= 


beq | bne | bit | bite j bgt j bgte 


labels 


l 






label mappings 


A : 


:= 


(1 1 I (71,... ,Z n • <7 n} 


programs 


P : 


:= 


Z 1 • B \ ; . . . ; In • B n 



Figure 3: Syntax for DTAL 



index variables 


a 




index expressions 


x,y 


::= a \ i \ x + y \ x — y \ x * y \ x + y 


index propositions 


P 


::= x<y\x<y\x = y\ x>y\x>y \ -1 P | Pi A P 2 | Pi V P2 


index sorts 


7 


::= int \ {a : 7 | P} 


index contexts 


0 


::= • | 4 >,a : 7 | <f>,P 



Figure 4: Syntax for type index expressions 



P = (copy : B\, loop : B 2 , finish : B 3 ) 

A (P) = {copy : a 1 , loop : 02 , finish : 173 } 

J(P) = copy; 7i; loop; I 2 ; finish; halt 
B\ = A(m : not, n : not, m < n).(Ri, Ii) 

B 2 = X(m : nat, n : nat, m < n,i : nat).(R 2 , P) 

7?3 — (Rempty , halt) 

<t 1 = state(X(m : nat,n : nat,m < n).Ri) 

(72 = state(X(m : nat,n : nat,m <n,i: nat).R 2 ) 

(73 — State(Rempty) 

Figure 5: The representation of the program in Fig 2 



types around in practice when we evaluate DTAL code as it 
is clear types play no role in evaluation of DTAL code. This 
is precisely like the case where a well-typed ML program is 
evaluated. 

We use J for a general instruction sequence in the follow- 
ing presentation, which consists of a sequence of instructions 
or labels. Given a block B = XA.X</).(R, I), we write a(B) 
for state(XA.X<j>.R) and 1(B) for I. Also we define functions 
A and J on program P = l\ : Pi; . . . ; Z„ : B n as follows. 

A(P) = {h : o-(Pi ), ... ,l n : a(B n )} 

J(P) = Zi;/(Pi);... ;Z„;/(P n ) 

We refer A (P) as the label mapping of P, in which we re- 
quire that all labels be distinct. For a valid program P, 
all labels in J(P) must be declared in A (P). In all the 



examples of DTAL code that we present in this paper, we 
attach the state type a of a label Z to the label explicitly 
in the program, and the label mapping of the program can 
be immediately extracted from the code if necessary. We 
explain these definitions in Figure 5, where the program P 
is given in Figure 2; Zj and I2 are the sequences of instruc- 
tions between the labels copy and loop and those between 
labels loop and finish, respectively. Pi is a mapping which 
maps 1 and 2 to (int)array(m) and (int)array(n), respec- 
tively, and Ri(i) = top for i ^ 1,2; R2 maps 1, 2, 3 and 4 to 
(int)array(m), (int)array(n), int(m) and int(i), respectively, 
and R.2(i) = top for i ^ 1,2,3, 4; R e m P t y (i ) = top for i in 
all its domain. Note that we write int for 3a : mt.int(a), 
that is, int is the sum of all singleton types int(a), where a 
ranges over integers. 

The following erasure function || • || transforms types into 
type erasures, that is, non-dependent types. 

||fop|| = top ||itmf|| = unit ||a|| = a ||int(a:)|| = int 

|| cr || = unit || 7 - array(a;)|| = ||r|| array ||3 (/>.t|| = ||t|| 

It can be readily verified after the presentation of DTAL that 
DTAL becomes a TAL-like language if one erases all syntax 
related to type index expressions. In this TAL-like language, 
the erasure of a program is well-typed if it is well-typed in 
DTAL. In this respect, DTAL generalizes TAL. We stress 
the erasure property because it indicates that DTAL does 
not make more programs typable than TAL but, instead, 
can assign more accurate types to programs. 




2.2 Dynamic Semantics 

We use an abstract machine for assigning operational se- 
mantics to DTAL, which is a standard approach. A machine 
state M is a pair (Tt, 7Z), where TL and 7Z are finite mappings 
which stand for heap and register file, respectively. 

The domain dom(7 ~i) of TL is a set of heap addresses, the 
domain dom(U) of 7Z is {0, . . . , n r — 1}. We do not specify 
how a heap address is represented, but the reader can simply 
assume it to be a natural number. Given h £ dom(77), TL (h) 
is a tuple ( hco , . . . , hc n ~ i) such that for * == 0, . . . ,n — 1, 
every hd is either a heap address or a constant. Given 
i £ dom(7l), TZ(i) is either a heap address or a constant. 

Given a program P, A = A(P) associates every label in 
J = J(P) with a state type a. We use length(J) for the 
length of the sequence J, counting both instructions and 
labels. We use J(i) for the ith item in J, which is either 
an instruction or a label. Also we write J~ 1 { l) for i if l 
is J(i ). This is well-defined since all labels in a program 
are distinct. We define a P-snapshot Q as either HALT or 
a pair ( ic,M ) such that 0 < ic < length(J). The relation 
(ic,A4) —>p (ic', M') means that the current machine state 
M transforms into M' after executing the instruction J(ic) 
and the instruction counter is set to ic' . 

Given M = (TL,1Z), we define the following. 



M(v) = 



0 if v is <) ; 

1 if v is integer i; 
l if v is label T, 

7Z(i) if v is the ith register n. 



Given a finite mapping / and an element x in the domain of 
/, we use f(x) for the value to which / maps x, and f[x i— > v] 
for the mapping such that 

rr \ f f(v) if V is not x ; 

J 1 ( v if y is x. 

Clearly, f[x i— > u] is also meaningful when x is not already in 
the domain of /. In this case, we simply extend the domain 
of / with x. 

We use the notation 7Z[r h -> he] to mean that we update 
the content of register r with he, that is, 7Z[r i— ► he] is really 
K[i w he], where i is the numbering of register r. Also we 
use M [ret he] for (TL,TZ[r h - > hc\) given A4 = (TL,7Z). 

We present some evaluation rules for DTAL in Figure 6. 
We do not consider garbage collection in this abstract ma- 
chine, and therefore the typing of the heap can only be af- 
fected by the memory allocation instructions newarray. No- 
tice that the rules (eval-load) and (eval-store) imply that 
an out-of-bounds array access stalls the abstract machine. 
These rules also indicate that the length of the tuple TL(h) 
can always be determined for every h £ dom(77) at run- 
time. We will soon design a type system for DTAL and prove 
that 0 < i < n in both rules (eval-load) and (eval-store) 
always holds when these rules are applied during the eval- 
uation of a well-typed DTAL program. Therefore, there is 
no need for determining the length of the tuple TL(h) for ev- 
ery h £ dom(77) if we only evaluate well-typed DTAL pro- 
grams. In the case where it cannot be determined in the type 
system of DTAL whether a subscript is within the bounds 
of an array, the array subscripting instruction is ill-typed 
and thus rejected. This sounds like a severe restriction, but 
it is not because we can always insert run-time array bound 
checks to make the instruction typable in DTAL (we give 
such an example at the end of Section 2.3). 



<j>; A; R a () : unit 



(type-unit) 



4>; A; R\~a i '■ int(i) 

A (l) = a 



- (type-int) 



4>\ A; R I- a l : a 
0 < i < n r 
4>\ A; R \~a n : R(i) 

/>; A; R \~a v : n (f>; A |= n < T2 



; A; R \- A v : r 2 



(type-label) 

- (type-reg) 

(type-sub) 



Figure 7: Typing rules for integers, labels, registers 



The rule (eval-newarray) is non-standard. If ||r|| is 
of form (e)array, then newarray[r]r, r' , r" allocates n new 
word-sized memory on heap, where n is the integer stored in 
r' , and initializes each word with the content in r" and then 
stores a point in r which points to the allocated memory. We 
emphasize that h must be new in the rule (eval-newarray) , 
that is, h is not already in the domain of Tt . The typing con- 
sequences of this memory allocation instructions is explained 
in the next section, where the typing rule (type-newarray) 
is introduced. 

Let us call a program well-structured if its evaluation halts 
normally (when the rule (eval-halt) is applied) or continues 
forever. In other words, the evaluation of a well-structured 
program can never be stuck. Certainly it is undecidable to 
determine precisely whether a program is well-structured, 
but this is also less relevant. We intend to find a conser- 
vative approach to examining whether a program is well- 
structured. Such an approach must be sound, that is, it 
can only accept well-structured programs. For instance, a 
straightforward approach is to adopt a method based on 
TAL for type-safety and then insert run-time checks for all 
array operations. Unfortunately, this approach seems too 
conservative, making it impossible to eliminate array bound 
checks. Notice that this is essentially the case in all JVML 
verifiers. In the next section, we present a less conservative 
approach based on a dependent type system. 

2.3 Static Semantics 

We present the typing rules for DTAL in this section. Note 
that we use an array representation for a register file R. We 
omit the standard rules for forming legal types and assume 
that all types are well-formed in the following presentation. 

We use a judgment of form (f>; A; R \~a v : r to mean that 
value v is assigned type r under the context (f>; A\ R and 
the label mapping A. The label mapping A is always fixed 
when we type-check a program, and therefore we will omit 
it if this causes no confusion. The rules in Figure 7 are for 
typing unit, integers, labels and registers. 

We present some typing rules for DTAL in Figure 8. We 
use 9 and 0 for index and type variable substitutions, re- 
spectively, which are defined as usual. Given a term • such 
as a type or a register file, we write »[0] (• [6*] ) for the result 
of applying 0 (9) to •. A judgment of form 0; A ;R h / 
means that the instruction sequence I is well-typed under 
context (j>; A; R. The notation R[r : r] means that we up- 
date the type of register r to r in R, that is, if r is the ith 
register, then we update the value of R(i) with r. We use 




-|| = (e)array J(ic ) = newarray[r] r,r',r” _M(r / ) = n > 0 h £ dom(77) 

( ic , M) — > p (ic + 1, Ad [ft h- > (M(r"), . . . ,M(r"))][r A]) 

J(ic) = load r d , r s (v) H(M(r a )) = (hco, ■ ■ . , hc n ~i) M(v) = i 0 <i<n 
( ic,M ) (ic+ 1 , Ad [r-d h-> /iCi]) 

J(ic) = store r d (u), u s M(r d ) h- ► h M = (TL,1Z) 

TL(h) = (hco, ■ ■ ■ , hcn-i) M(v) = i 0 <i<n M(v a ) = he 
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Figure 6: Some evaluation rules for DTAL 

4>,4>'\ A;R[r : r] b 7 
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(type-newarray) 

(type-add) 

(type-load-array) 

(type-store- array) 



A; R b jmp t>; 7 
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Figure 8: The typing rules for DTAL 



the rule (type-newarray) for typing arrays allocated on 
heap. We have explained in the previous section how mem- 
ory allocation is performed. Also we require that the index 
variables declared in 0 ' in the rule (type-open-reg) have 
no free occurrence in the conclusion of the rule. 

The typing rule (type-add) indicates that the type of reg- 
ister r d become int(x + 2 /) after the instruction add r d , r 3 ,v is 
executed, where we assume that r s and v have types int(*) 
and int(j/), respectively. If arithmetic overflow is to be con- 
sidered, we may require the instruction to be followed by 
an instruction that traps overflow; if an overflow occurs, we 
jump to a subroutine to handle it; otherwise, we know r d 
indeed has type int(* + y). 

We give some explanation on the rule (type-beq). We 
use (j> b 6 : cj) to mean that 8 is a substitution for <j> ' under 
c b , that is, for every a : 7 declared in <f>' , <j> b 8(a) : 7 is 
derivable and for every P in <// , (j> |= P[8\ is satisfiable. 
The explanation for <j>; A b 0 : A' is similar. Suppose that 
we type-check beq; r,v, I under 0; A; 72; we first check that 
r has type int(*) for some x\ we then type-check 7 under 
4>, x ^ 0; A; R (x ^ 0 is added into (j> since the jump is not 
taken in this case); we also verify that v has a state type 



and (j>, x = 0; A; R entails the state type (x — 0 is added to 
4> since the jump is taken in this case). The typing rules for 
other conditional jumps are similar. 

We sketch a case where a DTAL program that does not 
type-check can be modified to type-check with the insertion 
of a run-time array bound check. Assume that we want 
to type-check load r d ,r s (v)\I under <j>\ A; R, and we have 
verified that r s and v have types r array (x) and int (j/) , re- 
spectively, and we can prove <j> |= 0 < y but not <j> |= y < x\ 
we can then insert the following (where subscript is the en- 
try to some routine that handles errors) in front of the load 
instruction, and this insertion guarantees that x—y > 0 is al- 
ready added to (p when the load instruction is type-checked, 
making sure that y < x is provable. 

arraysize r, r s ; sub r, r, v; bite r, subscript; 

A dual case is to remove a redundant array bound check. For 
instance, we want to type-check bit r, subscript; 7 under 
4>\ A; R; suppose that r has type int(x) for some x and (j> |= 
x > 0 can be proven; this implies that bit r, subscript can 
never branch and thus this instruction can be removed. 

We use b P[well-typed] to mean that a program P = (h : 





B i, . . . , In : B n ) is well-typed and the following rule is for 
typing a program, where A is the label mapping of P. 

h A Bi [well-typed] • • • \~a B n [well-typed] 

b P [well- typed] 

Given a block B = AA.A 4>.(R,I), the rule for deriving \~a 
B [well-typed] is given as follows. 

<P-,A-R^ a I (type _ block) 

b a B [well- typed] 

3. TYPE EQUALITY AND COERCION 

As we have mentioned before, a novelty in DML is the 
separation between language expressions and type index ex- 
pressions. This notion of separation seems indispensable 
when we intend to form a dependent type system for an 
imperative language such as DTAL. For instance, it is com- 
pletely unclear at the moment how a register can be used as 
a type index expression, since it is mutable. The separation 
allows us to simply avoid such a problematic issue. Another 
advantage is that the separation enables us to choose a rel- 
atively simple domain for type index expressions so that 
constraints (on type index expressions) generated during 
type-checking can be efficiently solved. This is crucial to 
the design of a practical type-checking algorithm. In this 
section, we present type equality and coercion, which lead 
to constraint generation in type-checking. 

In the presence of dependent types, it is no longer trivial 
to check whether two types are equivalent. For instance, 
we have to prove that the constraint 1 + 1 = 2 in order to 
claim int(l + 1) is equivalent to int(2). In other words, type 
equality is modulo constraint satisfaction. Similarly, type 
coercion also involves constraint satisfaction. 

We use $ for index constraints, 

::= T | P | P D $ | Va : 7.$ 

and 0 (= P for a satisfiability relation, stating that (0)P is 
satisfiable in the domain of integers, where ( 1 f>)P is defined 
below. 

(■)$ = <f> {4>i a ■ = (< b)Va : mt.'F 

(0, a : {a : 7 j P})4> = (0, a : 7 )(P 3 <F) 

(^P)$ = W(PD< £-) 

For instance, the satisfiability relation a : nat, b : int, a + 1 = 
b |= b > 0 holds since the following formula is true in the 
integer domain. 

Va : int.a > 0 D Vb : int. a +l=bDb>0 

We currently only accept linear constraints, using linear in- 
teger programming to solve them. Though the constraint 
satisfaction is NP-complete, most constraints in practice are 
efficiently solved. 

We write 0; A |= n = T2 to mean that types n and T2 are 
equal under context 0; A. Similarly, we write 0; A |= n < T2 
to mean that type ti coerces into type T2 under context 
0; A. Note that type coercion can simply be view as a form 
subtyping here. Some rules for type coercion are presented 
in Figure 9. Notice that for the rule (coerce-exi-ivar-1), 
there is an obvious side condition requiring that the type 
t 2 does not contain free occurrences of the index variables 
declared in tj>' . 

The rules for type equality are similar and thus omitted. 



For instance, the following derivation shows that the type 
3a : nat.int(a) coerces into the type 36 : mf.int(b), where the 
the top applied rule is (coerce-exi-ivar-r) and the other is 
(coerce-exi-ivar-1). 

a : nat \= a : int a : nat - , ■ \= int(a) < int(a) 
a : nat; • |= int(a) < 3b : mi.int(b) 

•; • |= 3a : nat.int(a) < 3b : mt.int(b) 

We have so far finished the presentation of the type system 
of DTAL, which is rather involved. We will use a concrete 
example in the next section to provide some explanation on 
type-checking before proceeding to establish the soundness 
of the type system. 

4. AN EXAMPLE 

We demonstrate some key steps involved in type-checking 
the DTAL code in Figure 2. We stick to the notations 
given in Figure 5. Let insi be the ith instruction and I 2 
be insi; . . . ;insg for 4 < i < 9. In order to derive b 
£>2 [well- typed] , that is, to type block B 2 , we need to derive 
the following. 

m : nat, n : nat, m < n,i : nat; ■; R 2 b I 2 

Then there must be derivations XL with a conclusion of form 
4>i; At; Rt b l 2 ,j for i = 4,... ,9. We list these contexts 
<j>i; A;; Rt in Figure 10. In the derivation of 0 6', Ag; Re b I e, 
the last rule is (type-load-array), where we need to prove 
06 |= 0 < i < m. This is trivial since i : nat and i < m are 
assumed in 06- Similarly, we need to prove 07 |= 0 < i < n 
when deriving 07; A7; Rt b I7. This is also trivial since 
m < n,i : nat, i < m are assumed in 0 7. 

5. SOUNDNESS 

By the type soundness of DTAL, we essentially mean that 
the evaluation of well-typed DTAL code either halts nor- 
mally (when the instruction halt is executed) or goes on 
indefinitely. The main ingredient in the proof of the type 
soundness of DTAL is an entailment relation, for which we 
present a brief explanation. 

Given a program P, we use J for the list consisting of 
labels and instructions in P and J[ic] for the suffix of J 
starting with the ic th item in J. Assume 0; A; R b J[ic\ 
is derivable and there are substitutions 9 and 0 for 0 and 
A, respectively, such that M |= _R[0][$] holds, that is, M 
entails £?[0][0]. We use Tt \= he : r to mean that he has 
type r under the heap mapping 7i. For instance, we have 
Tt |= * : int(i). The following rule (heap-array) is for 
assigning array types. 

TL(h ) = (hco, ■■■ , hc n - 1) Tt |= hco : t ■ ■ ■ Tt \= hc n -i ■ r 
Tt (= h : (r)array(n) 

We write {Tt,TT) R, that is, (Tt, TT) entails R, if Tt |= 
Tl(i) : R(i) holds for every i £ dom(£). In other word, 
(Tt,lZ) \= R means that the content in each register does 
have the type assigned by R. 

We state the type soundness theorem for DTAL below. 

Theorem 5.1. Let P = (h : B\; ... ;l„ : B n ) be a pro- 
gram and A = A (P). Assume b P[well-typed\ is derivable 
and A(h) = R e m P t y , where R e m P t y maps each register to 
type top. For every machine state Ado. X/ (0,Alo) — >p 
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Figure 9: Some type coercion rules for DTAL 
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Figure 10: Contexts cj>k ; At; Rfc for k = 4, . . . ,9 



(ic, Al) then either (ic,M) — ► p iMLT, or(ic,M) — >p (ic' , M') 
for some ic' and M' . In other words, the execution of a 
well-typed program in DTAL either halts normally or runs 
forever. 

The proof of this theorem is involved. We have to deal with 
a subtle issue involving shared pointers and impose some 
regularity condition on the heap mapping Ti in a machine 
state in order to establish the result. We give some brief 
explanation on this issue. 

Suppose H(h) = (0) for some h, 7Z(0) = 77.(1) = h, R( 0) = 
(int)array(l) and R( 1) = (nat)array(l), where we write nat 
for 3a : nat.int(a). We can now derive (Ti,TV) \= R since 
(0) can be viewed as both an integer array of size 1 and a 
natural number array of size 1. Clearly, if we store a negative 
integer into the array pointed by n, then the type of r 2 is 
invalidated because it no longer points to a natural number 
array. 

Assume <j>\ A; R \~ J[ic] is derivable, M entails RfO]^] for 
some 0 and 9 and (M,ic) — >p (AC, ic 1 ), what we essentially 
need to prove is that <f> ; A'; Rl b J[ic'] is derivable for some 
cj>' and A' such that AC entails R , [0 , ][0']. Unfortunately, 
the above example shows that this is not provable as it is 
simply false. In order to overcome the problem, we impose a 
regularity condition on the derivation of Af |= R. Roughly 
speaking, we associate type r with heap address h whenever 
the rule (heap-array) is applied and a derivation is regular 
if a heap address is associated with at most one type. This 
notion of regularity is essentially the same as the notion of 
store typing in [2], which was used to address the circularity 
of references in ML. Clearly, there is no regular derivation 
for the above example: in order to derive A! \= R, we have 
to associate h with at least two distinct types int (when we 
derive Ti |= 77(0) : R( 0)) and nat (when we derive Ti |= 

tt(l ):«(!))■ 

In essence, by a regular derivation of (Ti, TV) |= R, we 
mean that there is a heap typing that maps each heap ad- 
dress h £ dom (H) to a fixed type and under this typing 
77(i) can be assigned the type R(T), that is, the value in each 
register has the type that is declared for the register. As a 



heap typing can never be altered (but it may be extended 
by the execution of newarray), We can then prove that if 
A! |= R[0][0] has a regular derivation then AC \= R' [0 , ][0 / ] 
also has a regular derivation, where we use the notation in 
the above paragraph. The proof bears a great deal of simi- 
larity to the soundness proof in [2]. 

In summary, if we start with an entailment that has a reg- 
ular derivation, then all entailments in the proof of the type 
soundness of DTAL have regular derivations. Therefore, the 
scenario of shared pointers mentioned previously can never 
occur. This allows us to establish Theorem 5.1. Note the 
issue here, which we think is rather subtle to recognize, does 
not occur in either DML or TAL. Please see [16] for details. 

6. EXTENSION WITH SUM TYPES 

The programmer can declare in Xanadu a polymorphic 
union type as in Figure 12 for representing lists and then im- 
plement the length function. The concrete syntax <’ a> list 
is for the type of lists in which all elements are of type ’ a 
(we use ’a for a type variable). Note that the union types 
in Xanadu correspond to datatypes in ML and the values 
of union types are decomposed through pattern matching. 
We informally explain the meaning of the switch statement 
in Figure 12; if xs matches the pattern Nil, the value of 
x is returned; if xs matches the pattern Cons(_, xs) (_ is 
a wild card), then we update xs with its tail and increase 
x by 1. The type following the keyword invariant states 
an invariant at the program point: xs is a list of length i 
and x is an integer of value j for some integers i,j satisfying 
i + j = n, where n is the length of the function argument. 

A union type is internally represented as a sum type. In 
the case above, a tag is used to indicate whether the out- 
most constructor of a list is Nil or Cons. We can compile the 
length function essentially in the following manner; we ini- 
tialize x with 0 and start the following loop; given a list xs, 
we perform a tag check to see whether it is Nil; if it is, we 
return x; otherwise, we know that the outmost constructor 
of xs must be Cons and it is unnecessary to perform another 
tag check; we can simply update xs with its tail, increase x 
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<j>, x = 0; A |= to < r ••• (j>, x *= n — 1; A |= r„_i < r 

0; A |= choose(x, to, . . . ,r„_i) < r 

</>; A |= r < Ti 0 |= x = * 

: (coerce-choose-r) 

(j>\ A = r < choose[x,To, . . . ,r n - i) 



Figure 11: Additional type coercion rules for sum types 



(’a) union list with nat = 

{Nil(O) ; {n:nat} Cons(n+l) of ’a * <’a>list(n)} 

(’a){n:nat} int (n) length (xs: <’a> list(n)) { 
var : int x = 0 ; ; 
invariant : 

[i:nat,j:nat I i+j=n] (xs : <’ a>list (i) , x:int(j)) 
while (true) { 
switch(xs) { 

case Nil: return x; 

case Cons(_, xs) : x = x + 1; 

> 

> 

exit; /* can never be reached */ 

} 

Figure 12: A list length function in Xanadu 

by 1 and loop again. 

We now extend the system of DTAL to handle sum types. 
In an implementation, we can use a pair on heap to represent 
a sum type sum{ro, ■ ■ ■ , T n -i), which is often written as ro + 
• • • + t„~ i in the literature. The first element of the pair is 
an integer i such that 0 < i < n and the second element 
is of type Ti. We can use choose(x, to, ■ ■ ■ ,t„- i) to stand 
for a type which must be one of to, ■■ ■ ,T n -i, determined 
by the value of x: the type is Ti if x = i. Also we present 
some additional rules in Figure 11 for handling type coercion 
involving sum types (rules for type equality are omitted). 
Now we can define sum(ro, ■ ■ ■ , t„- i) as: 

3 a : natn.int(a) * choose(a, to, ■ ■ ■ , t„~ i), 

that is, a value of type sum (to, . . . ,r n -i) is represented as 
a pair in which the first part is a tag determining the type 
of the second part. We present an example to illustrate the 
use of sum types. 

In Figure 12, we declare a dependent datatype in Xanadu 
for lists; Nil is given the type <’a> list(O), that is, it is a 
list of length 0; Cons is assigned the type 

{n:nat} ’a * <’a> list(n) -> <’a> list(n+l), 

indicating that Cons takes an element and a list of length n 
and yields a list of length n + 1. This leads us to represent 
the type constructor list as follows, 

fit.Aa.Iln : nat. (3(j>o .unit) + ( 3<j>i.a * ( a)t(a )), 

where /r is the fixed point operator and (j>o is n = 0 and (j>\ 
is a : nat, a + 1 = n. If we unfold (r)list{n) , we obtain the 
type ( 3(j>o-unit ) + (30i.r * ( r)list(a )), which can be folded 
into ( T)list(n ). It is straightforward to apply this strategy 
to a general case of dependent datatypes. We provide two 
auxiliary instructions f old[r] r and unfold r to indicate the 



need for folding the type of r into t and unfolding the type 
of r, respectively. 

The DTAL code in Figure 13 corresponds to the Xanadu 
program in Figure 12. The state type following the label 
length indicates that the top element on the stack is a list 
and the second one is a label; the list is the argument of 
the function and the label is the return address (pushed 
onto the stack by the caller); the type of the label states 
that the top element of the stack is an integer, which is 
to be the return value of the function, and the rest of the 
stack is the same as the current stack excluding the top 
two elements. The state type following the label length 
precisely indicates that this is a function that accepts a list 
of length n and return an integer of value n. We regard the 
representation of dependent datatypes at assembly level as a 
significant contribution, which makes it possible to perform 
compilation with dependent types for programs in DML and 
thus certify more program properties. 

The DTAL code in Figure 13 is unsatisfactory for the 
following reason. In practice, the list constructors are usu- 
ally represented without tags for both efficiency and mem- 
ory concern. In other words, we can interpret ( a)list as 
3a : nat 2 .choose(a,unit,a * ( a)list ). The reason is that 
it can be readily tested in practice whether a value equals 
() (which is commonly represented as a null pointer), and 
therefore there is no need for a tag. This optimized list rep- 
resentation can also be handled in DTAL. Please see [16] for 
details. 

The treatment of sum types extends the one in [3] . There 
indexed sums t\ +i T 2 (i = 1, 2) are introduced for types n 
and t 2 in addition to the standard sum ri + T 2 . The typing 
rules for indexed sums essentially state that for i = 1,2, 
ini(e) : ri +, T 2 is derivable if e : Ti is, where »; is used 
to indicate which rule is applied. To relate indexed sums to 
sum, there are subtyping rules for making ti +j T 2 a subtype 
of ti + t 2 for i=l,2. In DTAL, ti +i T 2 can be interpreted 
as int(* — 1) * chooseii — 1, ti, T2) and the subtyping relation 
can be derived with the use of type coercion rules. 

7. IMPLEMENTATION 

We have prototyped a type-checker and an interpreter for 
DTAL and verified many examples, providing a proof of 
concept. The implementation and examples are available 
on-line [14]. 

We have also prototyped a compiler which produces DTAL 
code from source programs in Xanadu, a language with C- 
like syntax in which only top level functions are supported 
and no pointers are allowed. Xanadu shares many common 
features with languages like Safe C [9] and Popcorn [6]. The 
most significant feature of Xanadu is its type system, which 
supports a restricted form of dependent types that are sim- 
ilar to those in DTAL, though registers are replaced with 





length: (’r, ’a){n:nat} [sp: ’a list(n) :: [sp: int (n) :: ’r] :: ’r] 

// [sp: int(n) :: ’r] represents the state type of the return 
// address (label) which is pushed on the stack by the caller. 

// Note that ’a list is represented as a dependent type internally 
pop rl // pop the list argument into rl 

mov r2, 0 // initialize r2 

loop: (’r, ’a){i:nat, j:nat I i+j=n} [rl: ’a list(i), r2: int(j), sp: [sp: int(n) :: ’r] :: ’r] 

unfold rl // 

load r3, rl(0) // load list tag into r3 (r3 = 0 or 1) 

beq r3, finish // goto finish if rl is empty (r3 = 0) 

load rl, rl(l) // rl: ’a * ’a list(i-l) (r3 = 1 since r3 is not 0) 

load rl, rl(l) // move list tail into rl 

add r2, r2, 1 // r2: int(j+l) 

jmp loop // loop again 

finish: (’r){n:nat} [r2 : int (n) , sp: [sp: int(n) :: ’r] :: ’r] 
pop rl // return address pops into rl 

push r2 // result pushes onto the stack 

jmp rl // return 

Figure 13: An implementation of the length function on lists in DTAL 



local variables in a program. Please see [15] for more de- 
tails. 

The compilation is like compiling C into a typical untyped 
assembly language except that here we need to construct 
state types for labels. We have compiled all the examples in 
this paper. 2 

In Xanadu, we allow the programmer to provide loop in- 
variants in the form of dependent types so that significantly 
more array bound checks can be eliminated in practice. In 
Figure 14, the top part is a program in Xanadu, which ini- 
tializes an array with zeros, and the rest is the DTAL code 
compiled from the program. The function header: 

{n:nat} unit initialize (int vec [n] ) 

indicates that for every natural number n, initialize takes 
an integer array of size n and returns no value. The type 
following the keyword invariant essentially states that i 
and 1 are of types int(a) and int(6), respectively, where a 
and b are natural numbers satisfying a + b = n. Note that 
n is the size of array vec. 

The Xanadu program can be compiled into the DTAL 
code excluding the state types for labels in a standard man- 
ner. This part is exactly like compiling a corresponding C 
program. We briefly mention the construction of the state 
types in Figure 14. Notice that the state type attached 
to loop is essentially translated from the type annotation in 
the source program. We simply modify the annotation to in- 
clude the types of variables not mentioned and then replace 
the variables with the registers to which these variables are 
mapped. We expect to formalize such a compilation strat- 
egy in future and show that a well-typed Xanadu program 
can always be thus compiled into well-typed DTAL code. 
At present, we may merely view the type annotations in 
Xanadu as compilation hints to generating well-typed DTAL 
code. 

2 We currently do not have a pretty printer for the generated 
DTAL code, and therefore we took the liberty to prettify the 
DTAL code presented in this paper. 



8. RELATED WORK 

There is a great deal of ongoing research on certifying com- 
pilers. Examples of certifying compilers for type and mem- 
ory safety include various ones compiling Java into Java vir- 
tual machine language (JVML), Touchstone compiling Safe 
C into a form of proof-carrying code (which we call TPCC) 
[9], TIL [11] and its successor TILT and FLINT/ML [10] 
compiling SML [5] into a typed intermediate language [11], 
and ROML [12] compiling a restricted set of ML into a por- 
tion of C that is type safe. 

DTAL is an extension of TAL with dependent types, and 
it can be readily transformed into a TAL-like language if 
one erases all syntax related to type index expressions. In 
this respect, DTAL generalizes TAL. In DTAL, initializa- 
tion is treated differently from in TAL. A type in TAL can 
be annotated with a flag to indicate the initialization sta- 
tus of a value with this type, but the type top is used in 
DTAL to represent the type of all uninitialized values. This 
strategy works because every array (and tuple if presented) 
is initialized upon allocation in DTAL. 

The notion of proof-carrying code introduced in [8] can 
address the memory safety issue in mobile code as follows. 
The essential idea is to generate a proof asserting the mem- 
ory safety property of code and then attach it to the code. 
The proof carried by the code can then be verified before 
execution. This is an attractive approach but a challenging 
question remains, that is, how to generate a proof to as- 
sert memory safety property of a (large and complex) pro- 
gram. The Touchstone compiler [9], which compiles pro- 
grams written in a type-safe subset of C into proof-carrying 
code (TPCC for Touchstone’s PCC), handles this question 
through a general verification condition generator [1], gener- 
ating verification conditions for both type safety and mem- 
ory safety. Also TPCC performs some loop invariant syn- 
thesis for eliminating array bound checks. In general, TPCC 
seems more involved in handling type safety when compared 
to TAL, while TAL seems less flexible than TPCC. 

DML is a functional programming language that enriches 
ML with a restricted form of dependent types [18], allow- 
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Figure 14: Implementations of an initialization function in Xanadu and DTAL 



ing the programmer to capture more program invariants 
through types and thus to detect more program errors at 
compile-time. In particular, the programmer can capture 
more invariants in data structures by refining datatypes 
with type index expressions. For instance, one can form 
a datatype in DML that is precisely for all red/black trees 
and program with such a type. The type system of DML is 
also studied for array bound check elimination [17]. 

DTAL stands as an alternative design choice to TPCC, ex- 
tending TAL with a form of dependent types that is largely 
adopted from DML. The design of DTAL is partly motivated 
by an attempt to build a certifying compiler for DML. Un- 
like TPCC, there are no proofs attached to DTAL code. The 
verifier for DTAL code is a dependent type-checker consist- 
ing of a constraint generator and a constraint solver. In 
general, proof verification is easier than proof search, and 
therefore the TPCC startup overhead should be less than 
that for DTAL code, though it seems too difficult at this 
stage to perform a meaningful comparison. In future, we 
are also interesting in constructing a proof asserting the 
well-typedness of DTAL code and thus provide a means to 
generating a form of proof-carrying code from programs in 
Xanadu. This is appealing as Xanadu allows the program- 
mer to formally supply program invariants that may be too 
sophisticated to synthesize and thus facilitates the construc- 
tion of proof-carrying code. 

We view DTAL as a type-theoretic approach to reasoning 
about memory safety at assembly level. With a stronger 
type system than that of TAL, DTAL is expected to capture 
program errors that can slip through the type system of 
TAL. This is supported by the fact that DML can capture 
program errors in practice which eludes the type system of 
ML. 



9. CONCLUSION 

TAL is a typed assembly language with a type system at 
assembly level. The type system of TAL contains some limi- 
tations that prevent certain important loop-based optimiza- 
tions such as array bound check elimination and tag check 
elimination. We have enriched TAL with a restricted form of 
dependent types and the enrichment leads to a dependently 
typed assembly language (DTAL) that overcomes these lim- 
itations. We have established the soundness of the type 
system of DTAL and implemented a type-checking algo- 
rithm. We have also constructed a prototype compiler which 
compiles Xanadu programs into DTAL, where Xanadu is a 
programming language with C-like syntax that supports a 
dependent type system similar to that of DTAL but signifi- 
cantly more involved. 

In future work, we intend to study compilation with de- 
pendent types, translating programs in DML into DTAL. 
We feel that the presented approach to representing depen- 
dent datatypes in DTAL has made a significant step towards 
achieving this goal. On a larger scale, we are interested 
in both using types to capture more program properties in 
high-level languages and constructing certifying compilers 
to translate these properties into low-level languages. 
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